AI Agent 框架实战解析：从聊天到落地

Hello-Agents 的第二部分里，第六章和第七章是我最喜欢的部分：讲清了理论，也给了可上手的实操，而且读起来并不费劲。

这两章的主旨，是介绍 AI Agent 的现成框架，以及“自己搭框架”这件事。什么叫框架？写代码的人都熟。我班门弄斧打个常见比喻：想象你要造一辆独轮车，最难的部分是那个轮子——其他零件都方方正正，唯独轮子要做成圆的，作为木匠的你很头疼。隔壁邻居说：我这儿正好有个现成轮子，你直接在它的基础上造车不就行了？于是你以后每次做独轮车，都去找邻居：“嘿，还有轮子吗？”邻居说：别重复造轮子，合作愉快。

用“轮子”当然有利有弊。好处是省时间、提效率，想量产就更明显；坏处是你的独轮车尺寸、结构在很大程度上受轮子约束，想加功能还得先确认轮子支不支持。甚至你怀疑轮子有问题，还得把邻居叫来一起排查。

那造 Agent 这辆“独轮车”，有哪些现成轮子？Hello-Agents 在第六章里介绍了 4 个：AutoGen、AgentScope、CAMEL、LangGraph。我还想补充一个它在前面章节提到、但这里没再展开的：CrewAI。

其中 AutoGen 很有意思。教程里说，它把多智能体系统抽象成一个由多个“可对话”智能体组成的群聊：开发者定义不同角色（比如 Coder、ProductManager、Tester），再设定它们之间的交互规则。任务的解决过程，就是这群智能体在群聊里通过自动消息传递不断对话、协作、迭代，直到达成目标。听起来有点魔幻：本以为是艰苦旅程，结果“聊着天就把活干了”？这让我想到微软另一个开源项目 TinyTroupe，也是用一群“小人”的对话来模拟群体行为。微软似乎确实偏爱这种风格。

Hello-Agents 在 AutoGen 这一节给了个案例，模拟真实的软件开发流程，设计了四个职责分明的智能体：

• ProductManager（产品经理）：把用户的模糊需求转成清晰、可执行的开发计划
• Engineer（工程师）：根据计划编写具体代码
• CodeReviewer（代码审查员）：审查代码质量、可读性和健壮性
• UserProxy（用户代理）：代表最终用户提出任务，并负责执行和验证最终交付的代码

此外还提到几个关键控制点：

• 参与者顺序：participants 列表顺序决定发言顺序
• 终止条件：termination_condition 用来控制协作何时结束；示例里约定消息包含 "TERMINATE" 就结束，由 UserProxy 在完成最终测试后发出
• 最大轮次：max_turns 是安全阀，避免对话陷入无限循环，浪费资源

但说实话，我看完的第一反应是：就这？感觉这帮 Agent 只是在聊天，没怎么“干活”。而且按固定顺序轮流说话，不能插话——这也太不“智能”了。

于是我干了件很直接的事：

1）git clone AutoGen 仓库 2）打开 Claude Code，问它：“开启 ultrathink 模式阅读 autogen 目录下的代码，告诉我开发者是如何用这个框架开发 Agent 应用的？”

它给我的总结大意是（我保留了关键信息）：

• AutoGen 是分层模块化设计：
  • autogen-core：核心接口和运行时
  • autogen-agentchat：单/多智能体工作流
  • autogen-ext：生态集成（模型、工具等）
• 典型用法包括： 1）单智能体：创建 AssistantAgent，挂上工具，run(task=...) 2）多智能体协作：如 Swarm 等模式协作完成复杂任务 3）工具集成：把函数注册为工具，让 Agent 通过 Tool Calling 调用
• 团队协作模式不止一种：
  • Swarm：基于 handoff 动态切换发言者
  • RoundRobinGroupChat：按固定顺序轮流
  • SelectorGroupChat：用选择器策略智能选择下一个发言者
• 还列出了一堆 sample 的位置（基础示例、GraphRAG、象棋、FastAPI team、可教学代理等）

到这里我才逐渐“对上感觉”：

• 原来协作模式并不只有“固定顺序轮流发言”。
• 原来可以做工具调用；也就是说，Hello-Agents 里的案例如果只呈现“聊天”，那更像是为了讲清概念，真正落地得靠 tool 去把“动作”接到真实世界，而不是光打嘴炮。

于是我继续追问它：“AutoGen 的示例代码里，有哪个集成了 tooling，并且不是按固定顺序轮流发言的？”

还真有：autogen/python/samples/core_streaming_handoffs_fastapi/

• ✅ 集成了工具：
  • 业务工具：execute_order、look_up_item、execute_refund
  • 移交工具：transfer_to_sales_agent、transfer_to_issues_and_repairs
• ✅ 动态选择策略（非固定顺序）：
  • 会基于工具调用结果，把任务路由给不同代理
  • 用语义分类器来决定下一个处理者

我又让 Claude Code 再深入读了读，发现这些业务工具（比如 execute_order）在示例里只是“模拟创建订单”（打印 + 返回订单信息）。但在真实应用中，你完全可以把它们替换成外部接口：连数据库、支付系统、ERP……只是返回给 Agent/LLM 的内容，往往会收敛成类似 {"product": "...", "price": 9999} 这种 JSON 字符串结果。

这么一看，确实开始有点意思了。

再回到 Hello-Agents 的那个案例：如果你给 UserProxy 配一个能执行 Python 的工具，它理论上就能帮你跑测试、看报错、再把信息反馈回来，然后进入下一轮对话继续 debug。感兴趣的小伙伴可以自己试试。